This invention relates to the control of telecommunications systems, and in particular of IP-based local networks for use in call centres, trading rooms and other applications. In systems designed for use in trading rooms of the trading financial services industry, it is common practice to provide a telecommunications terminal or “turret” for each user. Such networks provide a call server which handles incoming and outgoing call requests, and routes calls to the turrets appropriately.
Individual terminals are notified of changes of state of a Trunk or DDI (direct dial in telephone extension) in response to many kinds of call events, such as users going “on-hook” or “off-hook”. This specification will mainly discuss notifications made in response to incoming call attempts, but this is not intended to be limitative. When a call event occurs, the call server transmits alerts to any terminal to which the call is appropriate—depending on the type of call, this may be only one terminal—selected according to the dialled number, or the calling party, together with any call diversion settings or other user settings in force, as is described for example in United States Patent Application US2006153356 (Sisselman) and European Patent Application EP0740450 (IBM). However, in many cases the alert is sent to several, or even all, terminals connected to the server, as is described in International Patent Application WO20081071553 (Nokia). The way the system alerts the terminal may be selected by the user, as is described for example in German Patent specification DE3807006 (Telenorma).
In a system that is to operate in a converged network environment it is necessary to be able to measure the performance of the system in delivering call event notifications across many underlying network architectures, and also to predict its future performance. The overall performance of the system will be limited by the characteristics of the underlying network.
The telephony environment within a trading room has emphasis on team working. Users need to share the same Trunks or DDIs between several colleagues. Typically tens, but sometimes hundreds of terminals share the same Trunk/DDI. This sharing allows the users to see the activity of others on their telephony devices and provides fast access to allow them to dynamically join and create conferences. The users are commonly co-located. Prior art approaches, such as those described in European Patent Applications EP1521440 (AT&T) and EP2048863 (Ascendent) allow the selection of “sequential” ringing, in which a call event alert is routed to several termination points in turn, one at a time, in a sequence determined by the user, the call attempt being forwarded from each termination to the next if it is not answered within a predetermined period. Some systems, such as the AT&T system referenced above, also permit “parallel” ringing, in which a call attempt is routed to several termination points simultaneously. However, in the latter case, it is not possible to arrange for call alerts to be perfectly synchronised, because a typical digital processor performs operations in a sequence of steps, rather than strictly simultaneously. In a large installation, the time elapsed between the first and last alert can be significant, or the order of a second or two. It is very important that the notification of incoming call alerts and other state change events to all these terminals occur in a manner which maintains a democracy of service such that there is no perceptible delay when viewing the terminals. In very active or competitive environments this puts those who are not alerted to an incoming call first at a disadvantage, as they will have less opportunity to answer the call.
The fairness of call event notification delivery to endpoint devices is determined by several factors, such as the software architecture of the central call control server, the network topology, the network latency, any variation in packet delay, and end to end availability of multicast across the network and multicast replication delays
The software architecture of a Call Control server can typically choose from several mechanisms to deliver call event notifications. Sequential delivery of call event notifications to all registered users works well for small numbers of endpoints, but as the number of terminals grows the latency between the notification to the first terminal and the last terminal grows linearly. Alternatively, concurrent delivery of call event notifications to all registered users uses multiple threads of processing in the Call Control server to deliver the call notifications more efficiently than a sequential delivery. However, the number of threads that can be assigned to this task are limited by system resources and the maximum throughput of messages onto the network. As the number of registered terminals exceeds the number of available threads to deliver notifications the latency between the first and last notification will grow. This method leads to a “best effort” distribution of events.
Another variant for delivery of notifications is to use a multicast protocol, where all registered terminals are subscribed to a multicast group to receive the updates. This is a particularly efficient delivery mechanism as the Call Control server only has to send one message to deliver the event to all registered terminals. However, multicast protocols complicate the network design and make providing a resilient solution more difficult, especially if the scope of delivery is expected to extend to a WAN (wide area network) deployment.
Another variant is to provide a Call Distribution Module that deals with a small number of terminals. By having a three-tier architecture, the central call control server would send notification to only those Call Distribution Modules who have terminals attached with interest in the Trunk/DDI which initiated the alert. Each Call Distribution Module in turn forwards the message to terminals attached to it. As there are smaller number of terminals attached to each Call Distribution Module, this helps to maintain democracy between terminals for inter and intra Call Distribution Modules. However, again this approach is not appropriate for all network architectures, and in particular there may be difficulties in allocating individual terminals to their appropriate call distribution modules in a dynamic environment as users' requirements change.
According to the invention, there is provided a method of controlling a telecommunications server for controlling a plurality of telecommunications terminals connected to a packet switched telecommunications system, wherein the server responds to call events by transmitting a notification to each of the terminals, and wherein each terminal has a set of associated notification modes by which call events of specified types are notified to the user, characterised in that: the set of notification modes for each terminal are maintained in a store associated with the server and, for each call event, the server identifies the call event type and arranges the event notifications for the respective terminals to be processed in a sequence according to the notification modes specified for each terminal for the call event type associated with the current call event.
Another aspect of the invention provides a server for controlling a packet switching system for a telecommunications system, the server being responsive to call events to activate an event notification generator to transmit an event notification to each a plurality of telecommunications terminals connected to the system, characterised by the server being arranged, in the event of a call event, to identify the type of the call event, and to retrieve in respect of each terminal, from an associated store of terminal profiles, an event notification mode by which the event notification generator is to notify the respective terminal of call events of the type identified, and to process instructions to the event notification generator to transmit event notification alerts to the terminals in a sequence according to their respective event notification modes.
As discussed above, the call events may be call attempts received through an external network, in response to which the alerted terminals are capable of connection to the calling party in response to the call attempt. However, other call events may be the subject of alerts. The terminals to be alerted to a particular event may be selected from a larger plurality of terminals connected to the packet switched telecommunications system.
The store of user profiles may be updatable by each terminal to select an alert mode by which the event alert generator is to notify the terminal of one or more specified event types. The event types may relate to specified calling parties or predetermined classes of calling parties
Preferably, each terminal has a capability to select the mode by which an event alert of a specified type is notified to the user, such selections being transmitted to the store. The server may record the sequence in which it processes the event alerts for processing for each terminal, for a given specified type, and select the order of event alerts for subsequent calls of the same type with reference to the recorded sequence. This allows terminals of equal priority to be favoured in rotation.
This prioritisation of indication for call event notification provides a method to ensure a deterministic and democratic delivery on top of any of the delivery mechanisms described above or any other delivery mechanism. This invention therefore allocates a priority order to the network terminations such that the server sends an alert message to the terminals in a predetermined sequence. The sequence may be determined according to the users' likely interest in the call, so that all users with an interest in a particular class of incoming call are alerted first. The invention allows all callers having a particular interest in a call type to be alerted as near simultaneously as possible.
If the number of user terminals in a category is still too great to allow the server to alert all users simultaneously, it may be arranged to prioritise the users in each category in rotation. Thus a priority order is allocated to groups of users and the call server delivers events to the groups in priority order, to provide a deterministic delivery of call event traffic. The maximum size of a notification group will be determined to ensure that the latency of event delivery from the first user to the last user in the group is not perceptible at the terminal (turret), and will vary from one system to another depending on the latency of event delivery, on what interval is considered acceptable or perceptible, and on how many individual priority levels can be defined. In this way it is possible to ensure the democracy of event delivery and that no user within a group will gain an advantage.
The selection of which terminal are to be prioritised may vary according to characteristics of the call, such as calling party, number dialled, etc, and may be selected using features such as a user's own action declaring an interest in calls of a particular type. This may be a positive action such as selecting a priority level from a menu, but it is preferred for the selection to be implicit, to avoid users simply selecting the highest priority for all incoming calls. For example, a user may have set some call types to ring and others to provide only a mute (visual) alert. These settings can be used to prioritise the alerts: the user will be allocated a higher priority for those types which he has set to ring. Alternatively, the system may be set up so that an individual user can only set a predetermined number of call types to be high priority.
It should be noted that the number of users in each category may vary dynamically, depending on which users are currently connected to the system. If remote and/or wireless access modes are available as well as direct fixed connections, the access mode in use by each user may also be used to determine the user's prioritisation. In the case of mobile users, prioritisation may also take into account their current location, for example if users at a particular location are likely to be better equipped to answer the call.